I read in dxl reference that dxl is a scripting language
now if i change dxl script then it is not effected , we have to restart batch server of it.
So my fundamental question is that if it is a scripting language then it should take changes.
Please give me feedback whether i am right or wrong.
Thanks & Regards,
Hardik Shah
SystemAdmin - Wed Sep 08 07:24:35 EDT 2010 |
Re: Why we have to restart batch server if we change dxl script of it
Peter_Albert - Wed Sep 08 08:01:39 EDT 2010
I am not sure that I completely understand your problem, I am especially uncertain about what you mean with "restart the batch server of it".
It might be that you refer to the fact that changes to a DXL programme only take place for a module when it is closed and opened again.
This has nothing to do with DXL being a scripting language or not, but with the way DOORS loads modules from the server and builds up the window menus. When you open a module, all DXL is loaded and used to build up the menu structure. From now on, the DOORS client works on a local copy of all DXL files (I guess they are loaded into memory but I might be wrong here).
The point is that they are loaded once at the start and are not automatically updated when the "original" files change. But this has nothing to do them with being a scripting language or not. This only affects how programs are executed.
Consequently, when a DXL file has changed, you must close and re-open the module to take effect.
However, if your DXL file has one more #include statements, then modifications of the included files take effect without re-opening the module, but still require to re-start the script from the menu, as similarly, on script execution, I guess that all DXL code is first loaded into memory and then executed.
Best regards,
Peter
|
Re: Why we have to restart batch server if we change dxl script of it
llandale - Wed Sep 08 16:48:29 EDT 2010 Peter_Albert - Wed Sep 08 08:01:39 EDT 2010
I am not sure that I completely understand your problem, I am especially uncertain about what you mean with "restart the batch server of it".
It might be that you refer to the fact that changes to a DXL programme only take place for a module when it is closed and opened again.
This has nothing to do with DXL being a scripting language or not, but with the way DOORS loads modules from the server and builds up the window menus. When you open a module, all DXL is loaded and used to build up the menu structure. From now on, the DOORS client works on a local copy of all DXL files (I guess they are loaded into memory but I might be wrong here).
The point is that they are loaded once at the start and are not automatically updated when the "original" files change. But this has nothing to do them with being a scripting language or not. This only affects how programs are executed.
Consequently, when a DXL file has changed, you must close and re-open the module to take effect.
However, if your DXL file has one more #include statements, then modifications of the included files take effect without re-opening the module, but still require to re-start the script from the menu, as similarly, on script execution, I guess that all DXL code is first loaded into memory and then executed.
Best regards,
Peter
But the DXL themselves are loaded when invoked, and you do indeed see changes to the code between invokations from a menu pull-down. There is some delay, perhaps, when the DXL resides on some other computer (it may take 30 seconds after changing it before you see the changes) but that's a caching issue with the machines and nothing to do with DOORS.
But I don't think this is the Poster's issue, and yes he needs to explain it.
|